導語

AI 以超乎預期的速度席卷開發(fā)領域，AI 工程化也成為各業(yè)務團隊優(yōu)先探討的命題。輸入法團隊從實際需求出發(fā)，在Kuikly跨端項目中逐步探索并沉淀出一套 AI 工程化方案，目前已有不少需求按此流程完成開發(fā)并上線。以此文與大家分享其中的實踐經驗與思考，希望為同樣在 AI Coding 工程化路上探索的團隊提供一些可參考的思路。

Kuikly是騰訊廣泛使用的跨端開發(fā)框架，提供了使用Kotlin語言開發(fā)Android、iOS、鴻蒙、Web、小程序、MAC跨端應用能力。目前已在 QQ、騰訊新聞、QQ 音樂、搜狗輸入法、QQ 瀏覽器等30+業(yè)務深度使用，服務業(yè)務的總頁面數近2000+、日活用戶超5億，滿足了這些業(yè)務在眾多場景下的各類復雜需求。

一、背景

在AI時代，各業(yè)務團隊都在積極探索AI Coding，目標相似——希望實現需求自動關聯(lián)、代碼生成、效果測試一站式的AI愿景，達到“L3級別”的代碼生成。網上各類Vibe Coding演示，從0到1搭建Demo應用的過程已經相當流暢，似乎也印證了這一方向的可行性。

輸入法Kuikly跨端項目同樣面臨這樣的機遇，作為一個橫跨 Android、iOS、鴻蒙、H5 多端的復雜跨平臺工程，在跨端的背景下已經大幅提升了開發(fā)效率，新頁面通常由單人完成多端交付。而在 AI 時代，我們希望更進一步——借助 AI Coding 的能力，將開發(fā)效率再提升一個臺階。

從2025年下半年起，團隊開始逐步落地實踐。輔助問答、文檔查詢、代碼生成等能力確實為開發(fā)帶來了一定提效，但在面對完整頁面需求時，AI生成的代碼雖然能運行，但距離真正“可用”仍有差距。

存量工程理解有幻覺。輸入法 Kuikly 工程經過多年積累，已封裝了大量基礎能力，但 AI 對我們工程的理解仍存在明顯偏差，常出現 API 調用幻覺，遇到需求時傾向于重復造輪子等問題。此外，對于客戶端常見的頁面迭代場景，AI 也難有效處理。

需求缺乏結構化輸入。Vibe Coding 模式下，需求細節(jié)往往依賴開發(fā)自己補全，模糊的需求交給 AI，產出的代碼同樣缺乏準確性。當發(fā)現方向偏離時，往往已經經歷了多輪修改。需求中未澄清的部分越多，返工成本越高。

基于以上問題，我們思考：要讓AI在真實工程中真正發(fā)揮作用，實現真正的工程化，需要滿足哪些條件？輸入法跨端Kuikly項目也在實際的頁面開發(fā)中探索。

AI 工程化

在正式探索 Spec coding 之前，我們最初直接以 Vibe Coding 的方式使用 AI，隨后接入了 Kuikly 團隊提供的 AI 工具，在組件開發(fā)和小需求場景中已經有不錯的效果。在此基礎上，我們希望更進一步，通過更規(guī)范的流程讓 AI 協(xié)作真正走向工程化。結合我們真實需求開發(fā)中的實踐，我們梳理出我們項目推進 Spec coding 落地的幾個關鍵層面：

推進 AI 友好型工程

在討論 AI 編程效果不佳時，很多人第一反應是模型不行、提示詞沒寫好。但實際用下來，影響最大的往往是工程本身的質量。AI寫代碼會讀取項目上下文——已有代碼、模塊結構、依賴關系。如果工程本身質量不佳，會把 AI 帶偏生成出同樣混亂甚至相互矛盾的代碼。在人工開發(fā)時代，可以憑借個人經驗和約束規(guī)避，但在AI時代，它們會被直接放大為幻覺和錯誤。所以，如果你打算認真用 AI 來提效，與其研究各種高級的提示詞技巧，不如先回頭看看自己的工程，給AI做些針對性的優(yōu)化。

在這一點上，輸入法的 Kuikly 跨端項目具備較好的基礎。從項目立項之初，到多個平臺多個模塊的逐步擴展中，我們始終保持較為徹底的架構設計——頁面與業(yè)務邏輯分離、系統(tǒng)能力統(tǒng)一封裝、模塊間依賴關系清晰。正因如此，即使在尚未引入任何額外流程，對工程做額外調整的情況下，僅讓 AI 參考現有模塊生成代碼，就已經能有不錯的效果。

構建精準的AI Context

隨著模型能力的提升，模型的上下文窗口也變得越來越大，似乎可以將整個項目一股腦塞給 AI，但實踐中效果可能并非如期。對于開發(fā)者來說，哪些系統(tǒng)能力已經封裝、哪些基礎組件可以復用、哪些服務模塊應該優(yōu)先使用，往往是“默認常識”。

但對于AI，只能在龐雜代碼里盲目猜測和搜索，不僅容易漏掉已有能力、重復造輪子，也消耗大量token。另一方面，模型也是基于概率生成輸出，輸入信息的質量直接影響結果，塞入大量無關代碼，AI無法自行判斷重要性，輸出質量反而下降。

因此，我們構建了AI上下文文檔生成器Skills的基礎上構建了系統(tǒng)，為各模塊生成結構化文檔。保留AI需要的關鍵信息：模塊職責、核心 API 、參數含義、模塊依賴關系。將這些內容提前沉淀，為 AI 建立對項目的準確理解。同時，這類高質量的 Context 不只是服務于需求當前，在后續(xù)模塊迭代、修改、擴展時，它們也會成為穩(wěn)定的“工作記憶”，幫助AI保持實現思路一致、減少偏航，并在多輪協(xié)作中持續(xù)輸出更可靠的結果。

該系統(tǒng)的核心機制借鑒了 GAN（生成對抗網絡）的思想——文檔并非一次生成即定稿，而是通過生成器與評估器的多輪對抗迭代持續(xù)打磨。協(xié)調器設定逐輪遞增的質量門檻（第 1 輪 ≥75 → 第 2 輪 ≥82 → … → 第 5 輪 ≥95），每一輪由生成器產出文檔，評估器打分并給出改進建議，生成器據此修訂后再次提交評審，如此往復直至達到質量標準，最終輸出高質量的文檔，文檔從模塊職責、核心 API、參數含義、依賴關系等多個維度進行結構化描述，為 AI 提供更精準的上下文支持。

經過驗證，通過本系統(tǒng)改造后處理出新的文檔在多個指標上取得了提升：質量層面，文檔準確性達到與源碼完全一致、完整性覆蓋全部公開 API、示例代碼可直接復制使用。效率層面，新人上手項目提速 50%，理解模塊功能提速 107%，AI 編碼準確率提升 114%，文檔更新維護效率提升 137%，真正實現了"讓 AI 更懂工程、讓開發(fā)更高效"的目標。

標準化需求流程

工程化的一個特點是流程，在沒有流程約束的“提示詞開發(fā)”中，人與AI的協(xié)作是點對點、即興且不可復刻的。

這帶來幾個問題：

質量無法保證：在沒有統(tǒng)一流程、缺少明確約束的情況下，產出往往高度依賴兩件事：一是當次需求描述是否足夠準確，二是 AI 當下的“臨場發(fā)揮”是否穩(wěn)定。代碼質量波動巨大。

知識無法沉淀：個人開發(fā)摸索出來提示詞，有效經驗其實掌握在個人手里，每次開發(fā)都重頭開始，無法建立一套可復用，可持續(xù)的機制。

真正的工程化目標，并不是“讓大家都會寫提示詞”，而是要有一條標準化AI參與流程。只有這樣，AI 的能力才能從個人技巧走向工程化的目標。

在流程選擇上，我們結合近期的任務形態(tài)做了考量：當前大多需求時是新頁面開發(fā)，而一個客戶端頁面天然就是邊界清晰、目標明確、適合獨立交付的微型項目。因此我們最終采用了 Spec-Kit，它能很好地把 AI 協(xié)作納入標準流程，讓開發(fā)從“提示詞即興發(fā)揮”變成“基于明確規(guī)格的穩(wěn)定執(zhí)行”，關于 Spec-Kit 的原理和流程此處不再贅述。效果上，也讓Kuikly的同事嘗試過，基本可以復刻相同的效果。

Kuikly開箱即用的AI工具

在初步應用 AI 輔助編程的過程中，我們注意到，往往需要人工介入修改的地方集中在框架規(guī)則與實現技能兩個層面。有些問題雖然可以通過人工在后續(xù)迭代中能夠修正，但如果能提前通過工具補齊，整體效率會更高、代碼產出也會更穩(wěn)定。

原因在于，即使AI已經理解了具體的需求、項目上下文，但模型本身的訓練語料覆蓋仍然有限，對于項目中特定的能力邊界和最佳實踐認知不完整。針對這類問題，Kuikly 框架已經提供了一整套的 AI 輔助工具KuiklyAI編程指南，包括基礎的AI能力： MCP 服務、Rules、Skills，也提供了AI調試、D2C和AI轉碼這類針對特定場景的工具，覆蓋了從編碼、調試到遷移的多個環(huán)節(jié)。

目前我們主要使用了 Rules、Skills 和 MCP 這幾項核心能力，AI 調試工具、D2C 和 AI 轉碼等能力也在規(guī)劃接入中。實際使用下來，即便是直接以 Vibe Coding 的方式，配合這些工具也已經能取得相當不錯的生成效果，可以為 AI 補充Kuikly層面的知識，幫助它在生成代碼時更準確地理解組件、API 和相關約束條件，從而大幅減少調用幻覺和錯誤用法的出現。因此，在框架側的代碼生成上，業(yè)務并不需要過多操心模型理解Kuikly框架的能力，可以將更多精力聚焦在業(yè)務邏輯和存量工程的適配上?，F在Kuikly也提供了一件配置的CLI工具，Kuikly 團隊持續(xù)對這些 AI 能力進行維護和迭代更新，當框架側有新的優(yōu)化或規(guī)則補充時，可以通過 CLI 一鍵更新即可同步到最新版本，無需手動關注變更細節(jié)，實現真正的開箱即用。

同時，我們也結合自身項目在過往開發(fā)中積累的實際經驗和規(guī)范，進一步沉淀了業(yè)務使用上的 Rules，明確了架構層級和代碼層級的各項約定，從而在更細的粒度上引導和約束 AI 的編碼行為。

實踐與效果

以輸入法最新一期靈感詞庫功能頁面開發(fā)為例，靈感詞庫是搜狗輸入法鍵盤端的一個新功能面板，設計稿如下：

頁面細節(jié)上涉及動態(tài)多列布局適配、多種頁面狀態(tài)管理、暗黑模式切換，同時需要對接網絡請求、路由跳轉、輸入客戶端交互、KV 存儲、埋點上報等多項服務能力。此外，靈感詞庫作為一個持續(xù)迭代的功能，后續(xù)還會有二期需求演進，因此在頁面架構設計上也需充分考慮可擴展性，為后續(xù)迭代留足空間。

通過 Spec-Kit 的 /speckit.spec → /speckit.plan → /speckit.tasks 三個階段，將產品需求文檔、設計稿和交互稿做需求轉化為結構化的工程文檔。整個過程由 AI 主導，過程做了在關鍵節(jié)點做確認。最終輸出了一套完整的 Spec-Kit 文檔體系：

隨后進入編碼實施階段，便得到了一個 UI 與功能還原度都較高的版本，效果如下：

模塊組織、頁面核心框架、組件結構、布局邏輯均無需大改，主要集中在UI細節(jié)調整上。

對比傳統(tǒng)開發(fā)模式，同等規(guī)模的新需求模塊頁面搭建通常需要 3 天的純編碼和技術方案時間，而借助 AI 工程化流程，1 天即完成了主體開發(fā)。同時，得益于 Spec 文檔的前置約束和 Rules 的規(guī)范引導，生成的代碼在架構分層、狀態(tài)管理、跨端規(guī)范等方面都符合項目要求，代碼review階段基本不需要做架構層面的返工。

需要說明的是，上述效果主要體現在新模塊、新頁面的場景中。這類任務邊界清晰、依賴可控，AI 的完成度也比較高。而對于存量代碼的修改和跨模塊的深度重構等場景中，我們也嘗試過用同樣的流程去推進，但AI 的完成度目前還是因情況而異，穩(wěn)定性還不夠理想，后續(xù)還需要持續(xù)沉淀各類場景的 Skills，幫助AI更好理解任務。

展望

相較于傳統(tǒng) Vibe Coding，當前模式在迭代開發(fā)新模塊、新頁面搭建效率有不錯的效果提升。當然，距離 AI 全流程工程化的完整落地仍有一段路要走，我們也在以下幾個方向持續(xù)探索：

1. 打通 D2C 工具，減少 UI 修正成本

現階段，還有大量工作集中在 UI 層面的修正與調優(yōu)上，耗費了較多人力。如果能夠打通 D2C 工具鏈，將設計稿自動轉化為高質量的代碼產物，從源頭上減少 UI 還原過程中的人工介入，提升開發(fā)效率。在這一點上Kuikly團隊，也推出了視覺稿轉碼工具，未來我們的流程上也會持續(xù)往這方面繼續(xù)探索。

自動化驗證

隨著整體流程的跑通，仍有一部分環(huán)節(jié)依賴人工驗證。下一步我們計劃結合 Kuikly 預覽、Inspector 等現有工具能力，逐步構建驗證機制。通過 AI 自動化地對 UI 渲染結果、交互行為、布局一致性等進行校驗與反饋，逐步替代人工驗證環(huán)節(jié)，實現從"生成→預覽→驗證→修正"的全流程自動化閉環(huán)，進一步提升質量保障效率。

擴展更多場景

但實際開發(fā)工作遠不止于新頁面開發(fā)，后續(xù)我們計劃逐步將 AI 的能力延伸到更多場景——包括需求文檔的自動解析與任務拆分、線上 BUG 的自動定位與修復、跨端工程與端側工程聯(lián)動等，在實踐過程持續(xù)沉淀更多的 Skills 和工具，將各項能力與研發(fā)流程深度編排集成，讓 AI 在更多場景中發(fā)揮作用，逐步覆蓋到最終的完整交付鏈路。

當前Kuikly已經開源，有興趣和有需要的產品，可以通過以下方式訪問 Kuikly 倉庫，歡迎Star、Watch與體驗： Github 倉庫：https://github.com/Tencent-TDS/KuiklyUI

免責聲明：市場有風險，選擇需謹慎！此文僅供參考，不作買賣依據。

關鍵詞：